@ultramancode Thanks for the PR!

A few questions to understand the fix:

1. Do you handle the tool calling at your application level instead of Spring AI?
2. The MessageAggregator handles the Flux of ChatRespones at the later lifecycle where the AssistantMessage wouldn't have the tool calls. I am trying to understand why you would receive chunked assistant messages with tool calls at the MessageAggregator level.
3. Given you successfully manage to repeat this behaviour, Is it possible to have an integration test to repeat this issue? or, a specific model I can try to repeat this behavior?

Thanks

@ilayaperumalg Thanks for the detailed questions!

1. No, I'm using standard Spring AI flow. The issue occurs within Spring AI's internal streaming processing.
2. You're absolutely right to question this! In normal flow, MessageAggregator shouldn't receive incomplete tool calls. However, in the case described below, windowing fails and incomplete chunks leak through.
3. This bug is environment-dependent, making it difficult to reproduce reliably with live API calls. I've created unit tests based on the response pattern (MessageAggregatorTests). If you'd like to verify the bug scenario directly, simulating the streaming chunks from the issue log would be the most reliable approach.

Evidence from issue #4790

Chunk 1: `id="call_f7e76b4bdf8242b68b7124"`, `name="init_work_status"`, `arguments=""`
Chunk 2: `id="call_f7e76b4bdf8242b68b7124"`, `name=""` ← Empty!, `arguments="{\\"firstStep"`
Chunk 3: `id=""` ← Empty!, `name=""` ← Empty!, `arguments="\\": \\"开始需求"`

The symptom: These incomplete chunks reached MessageAggregator as separate ChatResponses, causing:

java.lang.IllegalArgumentException: toolName cannot be null or empty
at DelegatingToolCallbackResolver.resolve
at MessageAggregator.aggregate(MessageAggregator.java:91)

This proves windowing failed. If OpenAiApi.windowUntil() worked correctly, all chunks would have been merged before reaching MessageAggregator.

Why windowing fails with Qwen

The windowUntil() logic relies on detecting tool call completion:

return choice.finishReason() == ChatCompletionFinishReason.TOOL_CALLS;

Qwen's streaming either doesn't send the correct finishReason, or has other incompatibilities preventing proper window detection.

Related ecosystem issue:

• Qwen3-Coder #180 - Reports finishReason = "stop" instead of "tool_calls", function calling requires non-standard workarounds (e.g., specific system prompts), behavior inconsistent across deployments

Interestingly, Qwen's official spec documents finishReason = "tool_calls" as standard, but the implementation (especially via vLLM/OpenRouter) doesn't match the specification.

So windowing fails → incomplete chunks leak through → MessageAggregator receives them.

Why fix in MessageAggregator instead of OpenAiApi windowing?

Windowing approach (problematic):

1. Must distinguish "Qwen's buggy stop" from "legitimate stop"
2. Requires heuristics that could have false positives
3. Risk breaking existing OpenAI behavior
4. OpenAI-only - doesn't help other models

MessageAggregator approach (safe):

1. No distinction needed - just defensively merges any ToolCall chunks
2. Idempotent - already-merged ToolCalls pass through unchanged
3. No false positives - normal single ToolCall triggers no merging
4. Universal - protects all models that use MessageAggregator

Example scenarios:

Normal OpenAI (windowing works):

• Chunks merge correctly → 1 complete ToolCall → MessageAggregator sees it → passes through

Buggy Qwen (windowing fails):

• Chunks don't merge → 3 incomplete ToolCalls → MessageAggregator merges them → 1 complete ToolCall

-> MessageAggregator acts as a safety net without needing to know if upstream processing succeeded or failed.

A real-world concern: Integrating with existing LLM infrastructure

This isn't about supporting "broken" APIs—it's about bridging the gap between specification and implementation in real-world enterprise environments.

A scenario I'm concerned about (based on my experience):

I recently worked on an AI agent solution for a client where:

• Existing systems were already running on their deployed Qwen model
• The LLM infrastructure was managed by a separate team (not under our control)
• We had to integrate with the existing model, not replace it

The constraint:

• Cannot replace the model (other systems depend on it)
• Cannot modify vLLM/serving layer (managed by infrastructure team)
• Cannot control model deployment decisions (made at organizational level)
• Can only control the integration layer

While I didn't use Spring AI for that project, I'm concerned that Spring AI users will face the same situation: needing to integrate with pre-existing LLM infrastructure that has implementation gaps, with no ability to fix upstream components.

Thanks!